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Abstract 


The last paper published in the ARRL 
Networking Conference concerning TexNet was in 
1987 (1) and we felt it was about time to publish an 
update. This paper will discuss the current status 
of the Texas Packet Radio Society’s TexNet 
development, TexNet TexLnk software forthe TNC, 
and the TexNet CARDINAL project. We hope this 
paper will serve as a method to further distribute 
information regarding TPRS projects and be able 
to generate correspondence from interested parties 
about our activities. 


I ntroducti on 


Figure 1 shows the current status of the Texas/ 
Oklahoma/Arkansas network. The Texas and 
Oklahoma networks were joined in May 1990, 
adding an additional 400 miles of RF network. The 
future looks bright for further development and 
expansion of the network using both RF and landline 
links. Handling day to day problems on the network 
has now turned into a part-time job. Ever since the 
eighth network node, the network is in an ever 
changing state — nodes will break, get struck by 
lightening, fall off buildings, and about everything 
else you can think of will happen! The fun part of the 
TexNet network was in the designing, 
implementation, and deployment. Now an 
enormous amount of work is done in supporting 
node owners, keeping hardware working, and 
making the networkoperational. Building a network 
is fun, maintaining it becomes an effort of love. 
Many of the projects described in this paper are the 
results of now having a network large enough to 
finally test how TexNet works and operates. 
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Further expansion of the network outside of 
Texas will be possible by an agreement recently 
made with Southwest Network Services (SNS) for 
circuits to cities in Texas and other states. TPRS 
is the sole contact and coordination will occur 
through TPRS. Please do not contact SNS about 
this service. These are 9600 bps, point to point 
circuits, and TPRS intends to extend coverage of 
the TexNet networkto such cities having individuals 
wanting to support and join in the eff ort. A few cities 
available outside of Texas are Oklahoma City 
Tulsa, Baton Rouge, New Orleans, Birmingham, 
Atlanta, and Nashville. These circuits are available 
now. Future cities include Denver, Los Angles, 
San Francisco, Phoenix, and others. Those 
interested in SNS coordinated TexNet service 
should write TPRS. The possibility of extending the 
network coverage and allowing this service to act 
as a bridge to other TexNet-like networks is exciting 
(3). Also, the development of GLNET (2) in Michigan 
has been astonishing, occurring at a rate of about 
twice the Texas network expansion. Since Dayton 
‘90, 11 nodes are now operational. GLNET is 
currently the third working TexNet network outside 
of the state of Texas. 


Software Update 


TPRS has continued refining and improving 
the TexNet software, with the final version of 1.5 
being released this last June. TPRS has been 
utilizing version 1.4 of the TexNet code for 2 years, 
and predecessor versions from 1 .O over four years 
Versions 1 .0 and later provided automatic network 
routing, with automaticalternate routing. The routing 
function automatically builds the complete network 
map in a distributed fashion, as has been reported 
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Figure 1: 
Current TexNet network in 
Texas/Oklahoma/Arkansas. 
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previously (1). Over the last five years, the network 
has grown to 40 nodes, utilizing 9600 baud 440 
trunks, with over 1000 miles of radio paths at 9600 
baud and over 1500 miles total networking including 
landline connections. RF links in the entire system 
are on the same frequency (+/-2 PPM). Several links 
are 70 miles long without the benefit of mountains. 
During the last few years, we have observed a 
number of 440 MHz propagation openings. The 
Original design of the network software allowed 
programming of marginal-trunk lock-outs in each 
node image, to prevent slightly over-the-horizon 
conditions from causing routing events to bypass 
adjacent hops. Approximately ten 600+ mile 
propagation openings have occurred each year 
where the network routing has assumed adjacency 
between pairs of nodes 600+ miles apart. When 
e band opening ceased, the routes would then be 
Stale’ and the time it took for the new routes to be 
corrected was unacceptable. Another affect of 
band openings and node failures was the creation 
of asymmetrical routing in the network, which is 
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seen by having a good ‘to’ route but the ‘return’ 
route has failed, causing packets to be lost in the 
either. 


In late 1988 the TexNet Network Management 
System (NMS) was placed on the air to take care of 
wide-area network anomalies and manage day to 
day operations of the network. Creating this system 
both supported the short term problems in wide- 
area network support and allowed the long term 
development of an intelligent network supervisor. 
The NMS ‘polls’ each node in the system every 10 
minutes, and calculates network statistics. Each 
night at midnight, it uploads three network 
performance reportsto one of the network message 
servers. These reports show the retry rate, 
transmitted frame count, received frame count, 
buffer utilization, and number of user log-ons on 
every link on every node in the network for the day. 
Additionally, the outage-table shows each 
ten-minute slot during the day for each node, 
showing information on which particular nodes did 
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not respond to a poll (within 59 seconds). This 
information has been used to show time-of-day 
dependencies on network performance. 
Additionally, the NMS takes automatic corrective 
action at nodes that appear to be dead (don't respond 
within 59 seconds of a query). It is capable of sending 
a node-specific ‘fire-code’ sequence to fail-safe 
hardware in each node by broadcast-flooding this 
sequence throughout the network in order to 
remotely reboot any node. No operator intervention 
is required for any of these events, thus making the 
network more reliable. 


On February 17th, 1990, the TexNet Support 
Group met to discuss the future of TexNet software 
and to discuss the anomalies seen in the network. 
This meeting has led to the current 1.6 software 
now underdevelopment and testing. Version 1.6 is 
aimed strictly at correcting wide-area network 
operation anomalies which have only now been 
discovered with the network of this size. 


The new version 1.6 code fixes affected network 
trunk conditioning under extremely marginal signal 
conditions, but more importantly, allows remote 
manipulation of the network routing tables. This 
new network code allows the NMS to read and 
reprogram the network routing tables from a central 
location without any operator intervention. The 
new version of the NMS that supports this will allow 
for NMS to realign the network routing automatically 
to compensate for propagation anomalies, orcertain 
types of equipment failures. The network is still 
capable of automatically setting up its routes in a 
completely distributed fashion, but we can now 
offerover-riding ‘help’forthetables when necessary. 


TexNet TexLnk TNC Project 


The original TexNet code was developed on 
the TNC Il, until the first TexNet NCP (4) was built 
and the code moved to the NCP. After a year of 
working on the 1.4 and 1.5 code and examining the 
originally developed code, Jim Brooks, W5ERO, 
was able to get a single port version of TexNet code 
again operational on a TNC II. The project is now 
called TexLnk, since the purpose of TPRS getting 
this software working again was to create 
inexpensive high-speed links between network 
nodes and provide thin-route networking in West 
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Texas where the population of packet users does 
not demand full-blown TexNet nodes yet. The 
project was not done to create another, poo 
operating, single frequency network. TexLnk and 
CARDINAL, described below, are both intended as 
supplemental technology to allow more robust 
networking options. 


During the beta-test period, two high-speed 
linking nodes were deployed and have worked as 
expected, providing 9600 baud networking between 
sites with NCPs. This is accomplished by adding a 
TPRS 9600 baud modem as the external modem. 
One drawback to the current TNC version is that it 
does not support the hardware ‘firecode’ feature 
available on TexNet NCPs. Firecode allows the 
node to be hard-reset remotely by command. One 
of the nodes was equipped with a tone decoder 
reset and the other was not. The one without 
required a 35 mile drive to reset it, which has only 
been required once, since most problems can be 
corrected by a soft-reset which will still work without 
the hardware ‘firecode’ circuitry. 


TPRS has been hesitant in releasing this 
software to the public, since TPRS feels that people 
will try to make it work as a single-frequency 
network, which will work, but not give the same 
performance as TexNet. TexNet works well 
because: 1) the network trunks, which are on a 
separate frequency to avoid congestion problems, 
operate eight times faster than user access to the 
network, 2) the network software works very well, 
and 3) the quality network services provided to the 
user. TPRS is releasing this software as a 
‘SHAREWARE’ (5) product. Contact TPRS about 
getting a copy of the software and utilities. A 
manual, image editor, and paper on how ‘not to use 
itshould be available by the networking conference 
from TPRS. 


TexLnk provides the same software 
functionality as a full-blown TexNet node, except 
that it is a single port node. The features provided 
are : Digipeating, Conference Bridge, Networ’ 
Interface, and Local Console. For more informatio. 
on TexNet services refer to the TPRS TexNet 
User’s Manual (6) or the 73 article on TexNet 
published in October 1989. (7) 
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Two dual port projects are being worked on. 
‘4opefully an inexpensive dual-port solution will be 
~vailableinthecomingmonthstoallowthissoftware 
to be used as a low-cost dual-port TexNet node 
running on a TNC Il, providing 1200 baud local 
access and 9600 baud networking. 


CARDINAL Project 


The CARDINAL card is a communications 
coprocessor card foran IBM-PC XT/AT compatible 
computer. The design has been tested and is 
operational with boards in layout. CARDINAL 
allows vastly simplifieddevelooment of AX.25 based 
applications, network applications, and additional 
services or features for the TexNet network. The 
original intent of the CARDINAL project was to 
replace the first and only software development 
platform for TexNet (8). By having a plug-in card, 
we can now use the power of the PC for development 
and provide multiple cards to TexNet developers 
forfastercodedevelopment. Fromthe initialdesign, 
the current project has been worked on to allow the 
sard to do much more. 


CARDINAL contains almost identical 
components to the TPRS Node Control Processor 
(NCP) board that is used as the standard TexNet 
node. It contains 2 SIO/0 serial chips, a 280 
processor, Z80-CTC, 64K of RAM, a dual-port 
connectionbetween the Z80 andthe PC-XT bus for 
use of the RAM, and optional hardware breakpoint 
logic. The dual-port is actually just a standard 
single-port static RAM, but special logic on the 
board ‘steals’t he Z80 refresh cycles, and sequences 
the PC access during this time. This is a very 
cost-effective way to implement the dual-port 
hardware. The current TexNet code image runs, 
unaltered, on the PC-plug-incard. For the Z80, 
layer-2 drivers for versions 1 and 2 of AX.25 are 
available (for those who don't really care about TexNet) 
and a native TexNet layer-3 driver is developed 
and being debugged. All three have been proven 
operational at 9600 baud. 


The PC drivers allow the passing of data 
frames, and control requests fren the PC to the 
Z80 processor and vice versa. The Z80 acts asa 
coprocessor, and in fact, operates continuously 
even as the PC is rebooted with a CTRL-ALT-DEL, 


since the CARDINAL card ignores the PC-reset 
line. These drivers are supplemented by a TSR in 
the PC that periodically queries the 280 for 
completed send and receive packet activity. The 
TSR runs in the background, and will support 
shared ring-buffers for both transmit and receive in 
the PC RAM so that the application on the PC can 
ignore any real time aspects of the communication 
task. An application has been written in Borland’s 
Turbo-C that merely queues up transmit requests 
or examines received queues for incoming data. In 
this way, the PC application task needs to know 
almost nothing of the AX.25 or TexNet protocols, 
and have no timing constraints whatsoever. A 
simple network-capable multi-user read-only BBS 
with directory functions took less than 3 pages of 
‘C’ code to implement using these drivers. Since 
the function calls and buffer passage resolve all 
data and control possibilities via function codes, it 
is not necessary to parse ASCII strings to manage 
connection setup and teardown. 


Extensive debug utilities are written, that allow 
download of coprocessor software, single-step, 
breakpoint, register alteration, programmable trap, 
memory dumps, and disassembly of the current 
image. The debugger is written in ‘C’ and runs 
foreground on the PC, but can leave hardware 
traps and breakpoints armed before exiting. These 
armed traps allow debugging both the coprocessor 
and simultaneous applications on the PC. 


The low-level device drivers on the PC are 
based on ‘handles’so that the actual I/O addresses 
and the number of CARDINAL cards plugged into 
the PC can be easily selected by function calls. The 
device driver returns a ‘handle’ to the selected 
CARDINAL card. This facilitates changing the 
actual PC I/O address of the card, and allows 
multiple cards to be plugged into a single PC. The 
current card has up to 4 synchronous channels and 
straps on the CARDINAL card allow 4 different 
addressing ranges, resulting in the ability to 
construct a 16-port (synchronous AX.25) PC 
configuration. The TSR level drivers have 
programmable transmit and receive buffer ring 
sizes, allowing optimization for different 
applications. The PC drivers and TSR are written in 
8086 assembly language. 125 
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The native layer-3 interface to TexNet makes 
it fairly easy to add new and diverse network 
capabilities to TexNet. Applications being planned 
include support for other network types, database 
applications, DX Cluster support, a new weather 
server, and others. Having the application in the 
PC and not in the node, will allow us to get away 
from the current space constraints and having to 
write Z80 assembly for the TexNet NCP. 


An example usage of CARDINAL might be: a 
user at any node types the string: ‘Message @ 
CARDNAL’ and is automatically connected to and 
assigned a unique network-layer port number at 
the CARDINAL card. The network knows how to 
route the request (due to it’s automatic routing 
function) and the recipient node knows the entire 
layer-2 and layer-3 address from the network 
datagramstructure. Up to this point, the PC software 
hasn't done anything yet! The PC software is 
passed a buffer with the user connect call string, 
and the unique port and layer assignments by the 
280. This simple scheme facilitates adding new 
applications that appear to be part of the network, 
but without new users needing to know anything 
about callsigns, locations, or networktopology, etc. 
This maintains the transparent appearance to the 
user which is part of the TexNet network design. 
The ‘C’ application on the PC responds with either 
a log-on function, or an application selection query 
message to the user, depending on what the user 
has asked for. Plans are being discussed to add a 
services broadcast to version 1.6 which would 
allow users to know which services are available at 
which nodes on the network. 


Conclusion 


What comes after these projects for TPRS? 
Only time will tell, but some guesses are: providing 
more diverse services across the network, 
increasing networkthroughput either by increasing 
speed or by using data compression — allowing 
users to access the network faster, integrated 
voice and data networks, TexNet ported to other 
platforms, and probably a whole bunch of other 
brain storms we haven't even had yet. If you would 
like to Know more about any of the above projects 
or want to find out more about TPRS, please feel 
free to write. 
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NOTES: 


1. McDermott, Tom, N5EG. “Overview of the TexNet 
Datagram Protocol’. Proceedingsof the ARRL 6th Computer 
Network Conference. Redondo Beach, California. 1987. 


2. Great Lakes Network. Contact Jay Nugent, WB8TKL, 
3081 Braebum Circle, Ann Arbor, MI, 48108. 


3. “Southwest.Netwark Services”. TexNet Support Group, 


TPRS Quarterly Report. Volume 7, Issue 1, July 15th, 1990. 
p 18. 


4. Node Control Processor. The computer section of a 
TexNet node. 


5. SHAREWARE - If you use it, then please send in the 
registration per-node to TPRS so that we can keep working 
on new things. 


6. TexNet User’s Manual available from the TPRS for 
$1.00. 


7. Jones, Greg, WD5IVD. “TexNet Packet-Switching 
Network” 73 Amateur Radio. Issue 349 October 1989. 


8. The TESTBED node was the only memory residen* 
TexNet node built. Built by Tom Aschenbrenner, WB5PUC 
it was used to write all of the original version 1 .O code. 
TESTBED was an elaborate multiboard homebrew CPM 
system which emulated a TexNet node. 


